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ABSTRACT 

A plethora of diverse aspect mechanisms exist today, all of which 
integrate concerns into artifacts that exhibit crosscutting structure. 
What we lack and need is a characterization of the design space 
that these aspect mechanisms inhabit and a model description of 
their weaving processes. A good design space representation pro- 
vides a common framework for understanding and evaluating exist- 
ing mechanisms. A well-understood model of the weaving process 
can guide the implementor of new aspect mechanisms. It can guide 
the designer when mechanisms implementing new kinds of weav- 
ing are needed. It can also help teach aspect-oriented programming 
(AOP). In this paper we present and evaluate such a model of the 
design space for aspect mechanisms and their weaving processes. 
We model weaving, at an abstract level, as a concern integration 
process. We derive a weaving process model (WPM) top-down, 
differentiating a reactive from a nonreactive process. The model 
provides an in-depth explanation of the key subprocesses used by 
existing aspect mechanisms. 

Categories and Subject Descriptors 

D.2.I0 [Software Engineering]: Design; D.1.5 [Programming 
Tecliniques] : Aspect-oriented Programming; D.3.2 [Programming 
Languages]: Language Classifications 



General Terms 

Design, Languages 

Keywords 

AOP, AspectJ, DFD, Hyper/J, Open Classes, aspect mechanism, 
crosscutting concerns, definition, nonreactive, reactive, taxonomy, 
top-down classification, weaving process model (WPM). 



1. INTRODUCTION 

Concern integration is an essential process in aspect-oriented 
programming (AOP). Kiczales et al. [6] explicitly express the goal 
of AOP in terms of combining separate crosscutting concerns: 

"The goal of Aspect-Oriented Programming is to make 
it possible to deal with cross-cutting aspects of a sys- 
tem's behavior as separately as possible. We want 
to allow programmers to first express each of a sys- 
tem's aspects of concern in a separate and natural 
form, and then automatically combine those separate 
descriptions into a final executable form using a tool 
called an Aspect Weaver." 

The process of concern integration is called weaving, and the im- 
plementation of an "aspect weaver" — an aspect mechani.sm. This 
paper presents a top-down model of an aspect mechanism and its 
internal weaving process. 

1.1 Evolution of AOP Models 

A model primarily reflects understanding. We identify the fol- 
lowing evolutionary stages in the common understanding of AOP: 

1. (A X B ^ B) In early AOP models, an aspect mechanism 
was explained in terms of compilation semantics. This led to 
thinking about AOP in terms of code instrumentation, where 
an aspect program {pA G A) is woven into a base program 
(Pb,p'b G B). We refer to this initial understanding of AOP 
as the ABB model (Figure 1). 
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Figure 1: The ABB Model 

2. (A X B ^ X) Later, code instrumentation was found to be 
misleading and confusing in explaining the essence of AOP. 
When AOP was better understood, the compilation semantics 
was replaced with dynamic weaving semantics. The main in- 
sight was that crosscutting is an emerging property found in 



the composed program (px G X) rather than a pre-existing 
property in either pA £ A or ps £ B. We refer to this 
observation as the ABX model (Figure 2), named to corre- 
spond with Masuhara and Kiczales' ABX model of crosscut- 
ting [14].' 
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Figure 2: The ABX Model 

(C X R ^ X) More recently, the syntactical distinction 
between aspect (A) and base (B) has begun to diminish. 
In modem AOP languages, such as AspectWerkz [1] and 
Classpects [17], there is no essential distinction between as- 
pects and classes (as presumably will also be the case in As- 
pect! 5). The traditional, syntactical dichotomy into pA G A 
and pb G B is being slowly replaced with a semantical dis- 
tinction between concerns pc GC = AUB\R, expressed 
in either A or B, and integration rules pr G R, expressed in 
code, annotations, XML, or some other form. We introduce 
and refer to this model as CRX (Figure 3). 
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□ composed element 



Figure 3: The CRX Model 

Interestingly, the CRX model is very close to the original Hy- 
per/J model [16], taking this evolutionary path a full circle. The in- 
troduction of the CRX model as a general AOP model that explains 
both Hyper/J-like and AspectJ-like aspect mechanisms is a contri- 
bution of this paper and a direct result of a top-down approach. 

1.2 Problems with Current Models 

Models of aspect mechanisms have focused either on a selected 
mechanism, or on a bottom-up generalization of several mecha- 
nisms. In a bottom-up abstraction, a model is built by identifying 
and generalizing common patterns. Since each aspect mechanism 



'For consistency with the other models and to avoid confusion we 
use A to denote the aspect language and B to denote the base lan- 
guage, whereas Masuhara and Kiczales originally used A for the 
base language and B for the aspect language. 



is useful precisely because it does some crosscutting thing very dif- 
ferent, abstracting over several aspect mechanisms is difficult and 
often results in a fine-grained model which would likely need to be 
further extended to fit future aspect mechanisms." 

We distinguish between two general approaches to modeling as- 
pect mechanisms, namely, semantical and conceptual (Table 1, two 
left columns). Existing semantical models either explain a specific 
AspectJ-like Pointcut and Advice (PA) mechanism or generalize a 
PA model. Lammel [8] explains a join-point-and-advice mecha- 
nism named Method-Call Interception (MCI). Wand et al. [22, 15] 
explain an aspect mechanism for Aspect!. Walker et al. [21] define 
aspects through explicitly labeled program points and first-class dy- 
namic advice. Jagadeesan et al. [5] use PA to define AOP function- 
ality. Although very precise, all of these semantical models do not 
generalize over non-PA aspect mechanisms. 

An example of a conceptual model is presented by the work of 
Masuhara and Kiczales [14] on modeling crosscutting in aspect- 
oriented mechanisms. Theii aspect sand-box (ASB) [14, 20] frame- 
work generalizes over four mechanisms; Pointcut and Advice (PA), 
Open Classes (OC), Traversal (TRV), and Compositor (CMP). PA 
and OC are implemented by Aspect!; TRV is found in Demeter; 
and CMP is realized by Hyper/!. 

ASB belongs to the category of ABX models. Generally, ASB 
represents each aspect mechanism as a weaver that combines an 
aspect program and a base program into a result computation (or 
program) X. In ASB, a mechanism realizes a function with the 
signature: 

Ax B X META X 

where META stands for composition rules existing only in CMP' 
The weaver is said to model a weaving process, which is defined 
informally as [14]: 

"taking two programs and coordinating their coming 
together into a single combined computation. " 

The weaver's semantics is presented by an U-tuple structure: 

{X, X}-p,A, Ain, Aeff, ^MOD, B, Bid, -Beff, -Bmod, META) 

where A and B denote the languages of the input programs, X is 
the result domain of the weaving process, and X,jp are join points 
in X. The elements Am, Aeff of A and Bid , Beff of B provide 
a common frame of reference. Programs in A and B refer to Xjp 
using Aid and Bid and contribute their Aeff and Beff effects, 
respectively, to the semantics of the corresponding X computa- 
tions (program declarations). The remaining two elements, Amou 
and Bmod, refer to structures of modularity in the input languages. 

The introduction of a result domain X (that also coincides with 
our CRX model) is the main contribution of ASB. In ASB, join 
points exist only in X. An aspect mechanism combines semantics 
contributed by A and B at join points in X using the common 
frame of reference. A and B do not crosscut each other directly, 
but only with respect to X. 

The essential shortcomings of ASB are: 

• Syntactical dichotomy. ASB defines aspect mechanisms 
over an AOP language of a fixed syntactical form. Specif- 
ically, an AOP program is required to consist of an aspect 
program pA £ A and base program ps G B, both spec- 
ifying concerns. When the syntax of the AOP language is 



"This is a criticism of the term aspect-oriented being used today to 
describe a broad array of diverse programming mechanisms, rather 
than a criticism of bottom-up generalization per se. 
^^For all of the other mechanisms, META is left out of the model. 
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Table 1: Comparison of approaches to modeling aspect mechanisms 



different, the model includes it as a special case. Most no- 
ticeable, the META component was added so that ASB can 
also model Hyper/J. 

The definition of an aspect mechanism in ASB does not gen- 
eralize neatly over languages with similar semantics but a 
different syntactical structure. For example, Classpects [17] 
has no aspects, just classes. AspectWerkz [1] has no advice, 
just methods. In AspectWerkz, a method annotated as advice 
can be invoked explicitly as a method or implicitly as advice. 
This duality is difficult to explain in an ABX model due to 
its firm syntactical distinction between aspect (pA G A) and 
base (pb G B) programs. Furthermore, the annotations in 
AspectWerkz can be extracted and placed in a separate XML 
file. These XML integration rules are not in A, B, or X. 

AspectJ-based abstraction. ASB selects Xjp as the central 
abstraction found in all aspect mechanisms. In ASB terms, 
the common frame of reference is Xjp and the programs 
connect at the join points. While the concept of a join point 
is essential in PA, it is found in only a subset of existing as- 
pect mechanisms. Specifically, OC may be explained with or 
without join points (Section 5); it is unclear that join points 
are the right abstraction for TRV [9] ; and CMP does not in- 
volve join points in X at all [14, 20]. 

Coarse-grained process. In ASB, a join point in Xjp de- 
scribes a computation in X, and the computation in X is 
constructed using the join point in Xjp. Obviously, an as- 
pect mechanism must construct the join point prior to the 
construction of the corresponding computation it describes. 
ASB does not explain how this cyclic dependency is resolved, 
and generally lacks an explicit weaving process model. 

Over generalization. ASB takes upon itself to abstract over 
four mechanisms that do not necessarily share properties that 
can be reasonably generalized. PA and CMP are oblivious [4] 
and provide integration mechanisms. TRV, on the other hand, 
is not oblivious and provides an adaptation mechanism [9]. 
Yet, ASB generalizes over all of them [20]. To reconcile the 
difference between these four mechanisms, ASB provides 
a fine-enough grained structure. ASB's bottom-up general- 
ization underscores the similarities between various aspect 
mechanisms. What is lost in the generalization, however, is 
the ability to also understand their differences. 



1.3 Contribution 

This paper presents an abstraction in the opposite direction. Us- 
ing a top-down approach, we derive an abstract, yet precise, ar- 
chitectural model of the design space for aspect mechanisms. The 
model is build through analysis and design. The analysis phase 
characterizes the external behavior of an aspect mechanism. The 
design phase models the mechanism's internal behavior. 

The novelty of our model lies in its semantical rather than syn- 
tactical generalization. We define the aspect mechanism's domains 
over a semantical representation of an AOP program, which can be 
constructed from various syntactical forms. Our model explains the 
essential differences between various aspect mechanisms. It cate- 
gorizes aspect mechanisms according to semantical operations. 

Our CRX model emphasizes integration. The integration logic is 
defined by integration rules, separate from concern code defined by 
aspect or base programs. The CRX model provides a natural ab- 
straction for integration-based weaving processes. It captures the 
similarities as well as the differences between aspect mechanisms 
on various levels of abstraction. The top-down specialization re- 
spects individual features of different aspect mechanisms. For ex- 
ample, at the top level, the Hyper/J and AspectJ mechanisms are 
similar; and a deeper level reveals how different they are. 

1.4 Outline 

In Section 2 we analyze the weaving problem and present a gen- 
eral CRX weaving process model (WPM). The problem and the 
model are defined in abstract terms. They are constructed top- 
down, independent from any particular aspect mechanism. The 
top-down construction introduces different categories of a weaving 
process. In Sections 3 and 4 we design a nonreactive and a reactive 
specialization of CRX, respectively. We use concrete aspect mech- 
anisms to exemplify each category. In Section 5 we explain the du- 
ality of AspectJ's OC with respect to these categories. In Section 6 
we compare the CRX model to the ABX model, in terms of pro- 
viding a deeper explanation of AOP. Section 7 discusses how our 
classification of weaving processes is different from existing cate- 
gorizations of AOP languages. Finally, Section 8 discusses how the 
model can help in constructing new aspect mechanisms. 

2. ANALYSIS 

This section explains the fundamentals of the concern integration 
process at an abstract level. We begin by articulating what a weav- 
ing problem is, and what is a solution, termed a weaving plan, to a 
weaving problem. We then present a high-level model of a weaving 
process that explains the external behavior of an aspect mechanism. 
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Figure 5: CRX Weaving Process 



Figure 4: The Weaving Problem 

2.1 Weaving Problem 

An aspect mechanism implements a solution to a problem of 
concern integration. Intuitively, before separate concern elements 
can be "computed" they need to be woven together to produce 
a "computable" composed element. That is the job of an aspect 
mechanism. 

Per program, the problem of concern integration is to map the 
modularized program P, in which concerns are separated, to a com- 
posed program p, in which the concerns are woven (Figure 4). We 
denote the mapping by: 

r., weave 

Pi > p 

Abstractly, a program is either code or computation. A concern 
program, 

P= {ci,...,c„} 

is a set of n program elements, Cj £ C, j — 1, . . . ,n, where C is a 
domain of concern elements. A modularized concern program P is 
partitioned into pairwise-disjointed concern modules. For example, 
in Figure 4, P = Mi U M2 U M3. 
A composed program, 

p = {xi,..., x^} 

is a set of m program elements, Xi £ X, i = 1, . . . ,m, where X is 
a domain of composed elements and where the crosscutting occurs. 

2.2 Weaving Plan 

A solution to a concern integration problem is a weaving plan. A 
weaving plan establishes a mapping between elements of the con- 
cern program P and elements of the composed program p. A weav- 
ing plan is specified by a set of integration rules, 

g = {n, . . . ,rk} 

where 7?. is a domain of integration rules, and n £7i,i — 1, . . . ,k. 
The meaning of a weaving plan is a set of pairs, 

Igj — {(matchi,mixi) : Xi G p} 

where for every element Xi in p, matchi G 2^ is a subset of pro- 
gram elements, mixi : 2^ ^ p is a constructor, and the weaving 
plan satisfies the condition that Xi £ p is constructed by applying 
miXi to matchi. We denote this mapping by; 

matctii I — > Xi 

2.3 Weaving Process 

We model weaving as a concern integration process. An aspect 
mechanism constructs p by integrating concerns in P according to 



a plan g. In our model, the aspect mechanism implements a CRX 
weaving process (Figure 5). At each step of the process, the mech- 
anism accesses elements of P (the C-register), elements of g (the 
7?, -register), and elements of the about-to-be-composed program p 
(the A'-register). The mechanism produces new elements of the 
composed program p, and writes them to the A'-register. 

A weaving process is said to be nonreactive (Section 3) if does 
not depend on the state of the A'-register. A weaving process is said 
to be reactive (Section 4) if it requires read-access to the Af-register 
in order to produce the composed elements. 

The top level CRX process is the most general model of an aspect 
mechanism. In the next two sections we describe two specializa- 
tions of weaving process. We explain the semantics of these models 
by mapping them to well known aspect mechanisms. 

2.4 Notation 

We describe the weaving process using a sequence of data flow 
diagrams (DFDs) [24, 18, 23]. A DFD is a graph that models the 
data flow communication among processes and data stores. Cir- 
cles represent transformations. Pairs of parallel lines represent data 
stores. Arrows represent data. Collectively, a sequence of DFDs 
specifies the behavior of an aspect mechanism in terms of its inter- 
nal processes that transform data and the type of data being trans- 
formed. At the top level, a context diagram describes the overall 
system and its data flow interfaces with its environment. The con- 
text diagram is then decomposed into level- 1 processes, which are 
then decomposed into level-2 processes, and so on. 

We use the standard DFD convention for labeling processes. A 
context level DFD is numbered n.O. Level- 1 processes are labeled 
n.l, n.2, etc. Successive nested levels follow a similar numbering 
convention. This convention provides for easy tractability. We use 
the leading number n to relate a sequence of diagrams to the section 
where they are discussed. The first time a process is mentioned in 
the text, we indicate its label in parentheses. 

Note that a DFD does not specify when communications take 
place. In particular the labels are just identification tags and do not 
imply any specific processing order. 

3. DESIGN OF A NONREACTIVE WPM 

At each step of the weaving process, a nonreactive aspect mech- 
anism computes an element (or several elements) of the composed 
program p only from elements of P and g. In other words, the 
weaving plan of a nonreactive aspect mechanism does not consult 
the state of the A'-register in order to specify composed elements. In 
this section we informally introduce the inner working of a nonre- 
active aspect mechanism through an overview of the weaving pro- 
cess in Hyper/J. 

3.1 A Nonreactive Aspect Mechanism 

The CMP mechanism [16] of Hyper/J [19] is essentially a Java 
program transformer. In Hyper/J's terms, the input program P is 
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Figure 6: Nonreactive CMP mechanism 
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Listing 1: Personal View 

package personal; 
public class Person { 

protected String name; 

protected String dob; 

public String getName (){ return name;} 

public void setName (String name ) {this . name=name; } 

public String getDoB (){ return dob;} 

public void setDOB (String dob) {this . dob=dob; } 

} 



Listing 2: Tax View 

package taxes; 
public class Person { 

protected String name; 

protected String ssn; 

public String getName (){ return name;} 

public void setName (String name ) {this . name=name; } 

public String getSSN (){ return ssn;} 

public void setSSN (String ssn) {this . ssn=ssn; } 

} 



called a hypcrspace, the concerns are called hypcrslices (a hyper- 
space is a set of hyperslices corresponding to, e.g., Mi, M2, M3 in 
Figure 4), and the composed program p is called a hypcrmodule. 
The composition logic, called composition rules, is the weaving 
plan Q (Figure 6). P keeps the concerns separate, but does not spec- 
ify a coherent behavior. CMP generates p with the desired behavior 
by integrating the concerns together according to the composition 
rules g. 

The composition rules are specified in terms of unit trees. A unit 
tree is an abstraction of a program's abstract syntax tree (AST), 
where units represent nodes. In general, the rules define each hy- 
pcrmodule unit as a composition of multiple hypcrspace units. 

We explain the COMPOSE (3.0) process through a coding exam- 
ple. Consider two classes describing a person, one from a personal 



Listing 3: Hyperspace Specification 

-hyperspace 
hyperspace Person 

composable class personal.*; 
composable class taxes.*; 
concerns 

package personal: PersonalView 
package taxes: TaxView 



Listing 4: Composition Rules 

hypcrmodule Result 

hypersBces : PersonalView, TaxView; 

relationships : mergcByName ; 
end hypcrmodule; 



Listing 5: Composition Clauses 

hypermodule Result 

operations 

getName : equivalent (signatures (<PersonalView. getName, 

TaxView . getName> ) ) 
getDoB: identity (Signatures (<PersonalView. getDoB>) ) 
getSSN: identity (Signatures (<TaxView . get SSN> ) ) 
//the remainder of the operations code is omitted 

classes 

class Person 

instance variables: 

name : equivalent (types ( <PersonalView .Person . name, 

TaxView . Person . name>) ) 
dob: identity (types (<PersonalView. Person. dob>) ) 
ssn: identity (types (<TaxView. Person. ssn>) ) 

mapping 

getName: class Person 
CallAction : Sequence 

PersonalView. getName .Person 
TaxView . getName . Person 
getDoB: class Person 

CallAction: Simple PersonalView. getDoB . Person 
getSSN: class Person 

CallAction: Simple TaxView.getSSN. Person 
//the remainder of the mapping code is omitted 



perspective (Listing 1); another from a tax perspective (Listing 2). 
We can use Hyper/J to produce an integrated view. We start by 
specifying a hyperspace and a mapping of the classes to hyperslices 
(hyperspace concerns. Listing 3). The Person hyperspace defines 
two hyperslices, namely, PersonalView and TaxView. The for- 
mer consists of units found in the personal Java package, and the 
latter comprises units of the taxes package. 

The composition rules (Listing 4) define the Result hypermod- 
ule as a composition of the PersonalView and TaxView hyper- 
slices under the mergcByName composition strategy. The strat- 
egy specifies that same-name-same-type hyperspace units (e.g., the 
class units PersonalView. Person and TaxView . Person; or the 
method units PersonalView. Person . getName and TaxView. - 
Person . getName) should be merged in the hypermodule. 

Generally, the meaning of a composition rule depends on the 
structure of the input hyperspace. In our example, the result of the 
composition rules depends entirely on the hyperspace structure. 

The semantics for Hyper/J's composition rules [16] define a two- 



step composition process. The DFD in Figure 7 is an explosion of 
Compose (3.0). The first step is realized by the EXPAND (3.1) pro- 
cess, which expands the composition rules against the hyperspace 
unit tree into composition clauses (Listing 5).'* The composition 
clauses specify a hypermodule as a composition of specific hyper- 
space units. At the second step, the composition clauses and the 
hyperspace units are passed to the WEAVE (3.2) process, which 
composes the result hypermodule. 

In Listing 5, the operations section specifies how to compose the 
hypermodule operations (method signatures) from signatures of the 
hyperspace methods. The classes section defines a hypermodule's 
class-graph (classes and their instance variables) as a composition 
of hyperspace class-graph nodes. The mapping section introduces 
methods into the hypermodule classes by associating a hypermod- 
ule operation with a set of hyperspace realizations (method-body 
expressions) and a class. Thus, a composition clause defines a hy- 
permodule unit as a combination of specific hyperspace units. 

The weaving process is driven by the composition clauses. At 
each step (i), WEAVE (3.2) selects and applies a clause. The com- 
position clause specifies what hyperspace units to combine (matchi) 
and how to combine them (mixi). The process completes the step 
by composing a new hypermodule unit (composed element Xi ) and 
committing it to the composed program. The process terminates 
after all clauses were applied. 

4. DESIGN OF A REACTIVE WPM 

In this section we model a reactive CRX process. We present the 
model through an explanation of AspectJ's PA mechanism. 

4.1 A Reactive Aspect Mechanism 

The context level DFD in Figure 8 depicts a reactive weaving 
process of a PA mechanism. PA realizes a program execution pro- 
cess. Given a concern program P, a weaving plan g, and a compu- 
tation trace p, WEAVE (4.0) executes the program by constructing, 
transforming, and running computations. 

P and Q are constructed from an input program string. P consists 
of all the methods and advice-body expressions found in either the 
base (e.g., Java classes) or the aspect (e.g.. Aspect! aspects) parts 
of the input program, g is constructed from three sources: 

(1) pointcut designators; 

(2) pointcut-to-advice mapping; and 

(3) advice-to-type mapping. 

The first two elements provide collaboratively a mapping from join 
points to advice-body expressions. The last element provides a 
mapping from an advice-body expression to its advice type (before, 
after, or around), which is necessary for a proper weaving. 

p is a vector of computations that constitutes the composed pro- 
gram. Weave executes the program p by constructing computa- 
tions and running them. At each step of the process, WEAVE reads 
in the most recent computation in the trace, and executes it. The 
execution produces either a null-computation that wraps around a 
value or a set of sub-computations that extend p. 

Figure 9 is an explosion of WEAVE (4.0). ADVISE (4.1) and 
Evaluate (4.2) are level- 1 subprocesses. EVALUATE realizes an 
expression evaluator (a Java interpreter). This process executes the 
most recent p computation, and generally produces one or more 
join point computations Xjp. The ADVISE process intercepts a join 
point computation Xjp, and transforms it by wrapping it with advice 

''For readability, the actual composition clauses produced by the 
Hyper/J compiler were amended to resemble the notation in [16]. 
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Figure 8: Reactive PA Mechanism 




Figure 9: DFD 4.0: Weave 
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Figure 10: DFD 4.1: Advise and DFD 4.2: Evaluate 

computations. The computation produced by the ADVISE process 
replaces Xjp in the program execution. 

The PA mechanism represents a join point computation Xjp as 
a join point description descjp. The description provides the type 
of the join point computation (e.g., method call, method execution, 
constructor execution), values drawn from its evaluation context, 
and related static and lexical data. The join point description is a 
means by which EVALUATE passes information about the program 
state to Advise. The Advise process then uses this information 
for selecting the appropriate advice. 

A further breakdown of the PA's weaving process is depicted in 
Figure 10. Four subprocesses constitute a reactive weaving pro- 
cess. Match (4.1.1) and Mix (4.1.2) realize advice selection and 
advice weaving, respectively. MATCH selects pieces of advice by 
applying the jp—> advice mapping to descjp. The process returns 



the selected advice-body expressions as advice computations x*jj„ . 
Mix combines the advice computations with respect to their types 
with a join point computation xjp obtained from COMPUTE (4.2.1). 
The computation composed by Mix extends the execution trace p. 

The Control (4.2.2) process runs the most recent computa- 
tion in p. In general, the computation is built from a complex 
expression. Running the computation requires evaluation of the 
expression's subterms. CONTROL represents subterms as instruc- 
tions, and delegates their evaluation to COMPUTE. Since the pro- 
cess runs Mix-computations, the instruction set may include both 
base language (Java) instructions (e.g., method invocation instruc- 
tion), and aspect-specific (Aspect!) instructions (e.g., advice ex- 
ecution instruction). The COMPUTE process takes an instruction 
instr and produces a join point computation Xjp. The process also 
constructs a join point descjp that describes the computation. 

5. THE DUALITY OF OPEN CLASSES 

Open Classes (OC) is an aspect mechanism found in AspectJ that 
allows aspects to change the structure of a concern program. The 
mechanism realizes the semantics of inter-type declarations. An 
inter-type declaration construct associates a target Java type (what 
to change) with an OC effect (how to change it). 

There are two kinds of OC declaration effects; member and su- 
per type. A member declaration effect introduces a new member 
into the target Java type. For example, the following inter-type dec- 
laration introduces an observers field into the Point class: 



public Vector Point . observer s ; 



A super type declaration effect transforms the inheritance rela- 
tionship of the target type. It is specified by a declare parents 
construct. For example, the following declaration resets Point's 
superclass to be Observable: 



declare parents: Point extends Observable; 



5.1 A Nonreactive OC Mechanism 

We can explain the OC mechanism in terms of a nonreactive 
CRX weaving process (Figure 11). The concern program P con- 
tains OC effects and base program types (including aspect classes); 
the weaving plan q maps target types to the effects; and p is a Java 
program where the types and the effects are combined. 
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Figure 11: Nonreactive OC Mechanism 

The Weave (5.1) process iterates over P types. For each type. 
Weave selects the relevant OC effects using the g mappings. Then 
it transforms the type by applying the effects; and finally it commits 
the transformation result to the composed program. 

5.2 A Reactive OC Mechanism 

Interestingly, the OC mechanism can also be explained in terms 
of a static reactive CRX weaving process. A reactive OC mech- 
anism iteratively constructs an AST of a composed program. For 
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Figure 12: A simplified representation of a Java program's AST 




Figure 13: Reactive OC Mechanism 



clarity, we focus on a simplified representation of an AST that has 
four types of nodes, namely (from parent to children), root, type 
name, type declaration, and type member (Figure 12). 

The DFD diagram in Figure 13 depicts an (alternative) reactive 
model for OC. The model combines three processes: MATCH (5.2), 
Mix (5.3), and SELECT (5.4). Initially, the composed program p 
contains only a single root node marked as open. At each step, the 
mechanism selects an open parent node in p, populating its chil- 
dren with AST nodes drawn from P. That is, SELECT selects the 
parent from p and the parent's "base" child nodes child*g from 
the AST of the concern program P. MATCH selects OC effects as- 
sociated with parent, and translates them to child\ nodes.' The 
Mix process integrates the base and the "advice" children together, 
and commits the result to the composed program. The child nodes 
are marked open, with the exception of type member nodes, which 
are marked closed. Weaving continues until all p nodes are closed. 

A reactive OC resembles PA. An open node parent corresponds 
to a join point descjp, child*g correspond to a join point computa- 
tion Xjp, and child correspond to advice computations x*^^. 

The nonreactive and reactive alternative OC models illustrate 
different understandings of this mechanism. OC neither changes 
type names nor adds or removes types. The concern program types 
always end up in the composed program under the same name. This 
allows one to interpret the OC weaving plan mappings in two ways: 
as a mapping between concern types and effects, or as a mapping 
between composed types and effects. The first interpretation im- 
plies a nonreactive weaving process; the second, a reactive one. 



^child*^ are parent's children defined by inter-type declarations. 
For example. Vector Point . observers defines the observers 
field as a child of the Point class declaration. 



6. BEYOND CONCEPTUAL MODELS 

The CRX model affords deeper understanding of an aspect mech- 
anism and its internal weaving process. 

6.1 Abstract Domains 

In CRX, the abstract AOP language representation overcomes 
the syntax dependency problem found in ABX. CRX defines the 
mechanism in terms of concern elements (domain C) and integra- 
tion rules (domain TZ). These domains abstract away from any 
concrete representation. A program in a concrete AOP language 
syntax, e.g., in AspectJ, can be preprocessed, e.g., by a READ (6.0) 
process (Figure 14) that reads pA and pb in and writes P and g 
out, which in turn can be used by WEAVE (4.0, Figure 8). Conse- 
quently, the CRX weaving process model generalizes over asym- 
metric (e.g., AspectJ) and symmetric (e.g., Hyper/J, AspectWerkz, 
and Classpects) AOP languages uniformly. 




Figure 14: Syntactical versus semantical 

6.2 WPM as a Unifying Concept 

The CRX process model reveals that join points are only used 
in reactive mechanisms. Nonreactive mechanisms do not use join 
points because they do not read from the composed program regis- 
ter X. In other words, the existence of a join point abstraction can 
be used to distinguish rather than unify various aspect mechanisms, 
e.g., PA is a join point-based mechanism, CMP is not. 

A CRX weaving process model was constructed top-down using 
abstract terms. The abstract terminology is useful for comparing 
different weaving processes. Zooming out highlights the similari- 
ties. Zooming in exposes differences. For example, at the top level 
both CMP and PA realize the same CRX weaving process. How- 
ever, they fall into two different categories. CMP is a nonreactive, 
whereas PA is a reactive mechanism. 

6.3 Cyclic Dependency in AspectJ 

Aspect! has a cyclic dependency between a computation in X 
and the join point in Xjp that describes that computation. The 
CRX weaving model (recall Figure 10) explains how the cyclic de- 
pendency is resolved in the PA weaving process. Specifically, the 
join point descjp describes the join point computation Xjp rather 
than the composed program computation. Thus, the join point is 
created before the composed computation is constructed. 

6.4 Advising Advice Execution 

ASB's view that PA selects and merges base and aspect program 
elements at each join point does not explain weaving at advice exe- 
cution join points. Clearly, at advice execution join points, no base 
element should be selected. The role of base is played by a piece 
of advised advice. ASB does not generalize over advice execution 
join points because it explains advised elements strictly as base. 

In contrast, the CRX weaving model of PA (Figure 10) distin- 
guishes between a join point computation (an advised computa- 
tion), and an advice computation. The join point computation (Xjp) 



is produced by the evaluator's COMPUTE process as a result of run- 
ning p computations. Since p generally contains previously wo- 
ven advice computations, the join point computation might be an 
advice execution computation. Thus, the CRX weaving process 
model also explains how advice executions are advised. 

6.5 Untangling Evaluate and Advise 

The reactive CRX model of PA explicitly separates EVALUATE 
(interpreting process) from ADVISE (advising process). EVALU- 
ATE selects and computes the meaning of advised elements (e.g., 
methods). ADVISE selects advice, computes their meaning, and 
weaves them. In contrast, ASB modifies the interpreter to include 
aspectual operations. For example, in ASB's PA mechanism, calls 
to lookup-advice are scattered throughout the interpreter and 
tangled with calls to lookup-method. 

7. TOP-DOWN CLASSIFICATION 

Our top-down analysis yields a process-oriented classification of 
aspect mechanisms. At the top level, we distinguish between a 
reactive and a nonreactive mechanism. In this section we compare 
our classification to existing categorizations of AOP languages. We 
show that our classification is different, and explain its usefulness. 

7.1 Symmetric versus Asymmetric Languages 

Today, existing AOP languages are sometimes categorized using 
the syntactic property of symmetry. Under this view, AspectJ is 
asymmetric — an AspectJ program consists of a base Java program 
and a set of aspect definitions. Hyper/J is said to be symmetric — all 
concerns are written in Java. 

Unfortunately, this view does not provide much insight into the 
essential difference between AOP languages. It fails to explain 
how Hyper/J differs from AspectJ on a semantical level. Worse 
yet, under the symmetry-based view, "symmetrical" AspectJ-like 
languages (e.g., AspectWerkz and Classpects [17]) fall into the cat- 
egory of Hyper/J, instead of sharing a category with AspectJ. 

Our approach abstracts away from the syntax of a language, and 
focuses instead on the weaving process that realizes its semantics. 
We represent an input AOP program in a syntax-independent man- 
ner, through sets of concern elements and integration rules. 

We explain the working of an aspect mechanism according to 
its semantical operation. The reactive PA weaving process (Fig- 
ure 10) explains AspectWerkz and Classpects in exactly the same 
manner as it explains AspectJ. Our classification identifies that As- 
pectWerkz, Classpects, and AspectJ are all reactive aspect mecha- 
nisms, and contrasts them with the nonreactive Hyper/J CMP. 

7.2 Static versus Dynamic Languages 

Another classification approach categorizes AOP languages as 
static or dynamic. A static language expresses a weaving process 
over an abstract syntax tree (AST). For example, Hyper/J dictates 
the construction of a hypermodule unit tree from a hyperspace unit 
tree, where units represent AST nodes. Hyper/J is often referred 
to as a static AOP language. A dynamic AOP language allows the 
expression of concern integration logic over computations, using 
run-time abstractions. For example, advice weaving in AspectJ is 
defined in terms of join points in the program execution. AspectJ 
is often said to be a dynamic AOP language. 

In our approach the weaving problem and the general CRX weav- 
ing process model are abstracted in terms of concern and composed 
elements. Identifying the composed and concern elements as AST 
nodes yields a weaving model for static languages. Defining the 
elements to be computations yields a weaving model for dynamic 
languages. Although it is tempting to think that nonreactive aspect 



mechanisms are always static, and reactive aspect mechanisms are 
always dynamic, it is not so. Specifically, the static OC mechanism 
can realize a reactive weaving process. A reactive-nonreactive 
classification is, therefore, fundamentally different than a static- 
dynamic one. 

7.3 Static versus Dynamic Semantics 

Aside from the static-dynamic classification of AOP languages, 
there is an analogous classification of AOP language semantics. 
Semantics for dynamic AOP language can be specified in terms 
of code transformation. It is also possible for static languages or 
mechanisms to be given dynamic semantics. 

In our approach, a weaving process always maps to a specific 
semantics, either static or dynamic. Alternative semantics for the 
same AOP language are normally realized by different weaving 
processes. For example, compilation semantics for Aspect! can 
be realized by a static nonreactive mechanism; dynamic semantics 
for Aspect! can be realized by a dynamic reactive mechanism. 

8. TOP-DOWN CONSTRUCTION 

A property of our top-down approach for modeling a weaving 
process is the ability to systematically construct new aspect mech- 
anisms. The mechanisms can be derived in a step-wise refinement 
of the general CRX weaving process model (Figure 5). For exam- 
ple, the reactive PA mechanism model (Figure 10), which refines 
the general CRX weaving process model, can be further special- 
ized to produce a concrete weaving process specification. 

8.1 Component-Based Design 

In our approach an aspect mechanism is modeled by a set of col- 
laborating subprocesses. A component-based design [12] for an as- 
pect mechanism would support a decomposition of an aspect mech- 
anisms into distinct processes. In such a component-based design, 
it would be possible to replace and reuse subprocesses, thus facil- 
itating aspect mechanism evolution. For example, the reactive PA 
weaving process model decouples the interpreter functionality from 
the aspectual advice selection and weaving processes [13]. The in- 
terpreter operations are realized by CONTROL (4.2.2) and COM- 
PUTE (4.2.1). Match (4.1.1) and Mix (4.1.2) realize the match 
and mix aspectual functionality. 

Decomposing the aspect mechanism into subcomponents affords 
replacement of one component at a time. Consider two reasonable 
enhancements to Aspect!: extending the pointcut designators with 
new regular expressions, and adding new types of advice. Each 
enhancement requires replacement of exactly one component. Ex- 
tending the original MATCH component to handle new regular ex- 
pressions would enable the pointcut designators enhancement. To 
extend the advice type set, the Mix component should be upgraded. 

8.2 New AOP Functionality 

Most (if not all) the weaving processes that exist to date con- 
struct the composed program by extending it with new elements. 
For example, the advice weaving process in PA simply extends, 
at each step, the composed program's computation trace with new 
computations. Aspect! never transforms computations within the 
composed program (i.e., an already executed or currently active 
computations). Similarly, the weaving processes of CMP and OC 
never change elements of the composed program. 

The general CRX weaving process model (Figure 5) lends itself 
toward inventing novel weaving functionality beyond current prac- 
tices. The model defines an aspect mechanism as a composed pro- 
gram transformer. At each step of the weaving process, the mech- 
anism transforms the composed program p. Under this view, the 



process may include steps that actually modify or replace elements 
in p. For example, one can imagine a dynamic reactive process 
that would update currently active computations (e.g., transform 
the current continuation). Another example would be a static reac- 
tive process that can extend p with new AST nodes, and transform 
previously composed AST nodes. 

9. CONCLUSION 

This paper characterizes the design space for aspect mechanisms. 
An aspect mechanism is an implementation of an aspect weaver. 
We model weaving as the process of concern integration, and de- 
fine the weaving process in an abstract way, independent of any 
specific aspect mechanism. The abstract model describes the de- 
sign space, and concrete aspect mechanisms are derived top-down 
from the abstract model. We distinguish between reactive and non- 
reactive mechanisms. This taxonomy provides a common frame- 
work for comparing and contrasting different aspect mechanisms. 

We offer a new CRX model as the next evolutionary step in mod- 
eling aspect mechanisms. In CRX, integration rules in R govern 
the process of integrating concerns in C into crosscutting struc- 
tures in X. We formalize the CRX model as a weaving problem 
over corresponding abstract domains TZ, C, and X. A CRX weav- 
ing process executes a solution to a weaving problem. 

The weaving processes are classified as either reactive or non- 
reactive, instead of the more classic static-dynamic or symmetric- 
asymmetric classifications of AOP languages. We design a nonre- 
active CRX process for the static CMP aspect mechanism of the 
symmetric Hyper/! language. We design a reactive CRX process 
for the dynamic PA aspect mechanism of the asymmetric Aspect! 
language. We also design both a nonreactive and a reactive CRX 
processes for the static OC aspect mechanism of Aspect!. 

Our top-down model overcomes many limitations in other mod- 
els in terms of abstraction, precision, and uniformity. The model 
was not generalized from a particular set of aspect mechanisms, 
yet existing mechanisms can be mapped, analyzed, and explained 
in terms of this model. In contrast, other models are generally con- 
structed bottom-up by analyzing existing aspect mechanisms. The 
generality of these bottom-up models is illustrated by expressing in 
teiTns of the model only the mechanisms used to derive them. 

The design space for CRX aspect mechanisms can help not only 
classify existing mechanisms but also develop new ones. It can 
guide the implementor of new aspect mechanisms in existing classes. 
It can also guide the designer when mechanisms implementing new 
kinds of weaving are needed. We have used the CRX model in 
researching third-party composition of aspect mechanisms. The 
model was particularly useful in resolving sequential black-box 
composition of heterogeneous aspect mechanisms [7] and parallel 
glass-box composition of homogeneous aspect mechanisms [II]. 
Future work may include extending the CRX model to also de- 
scribe a multi-mechanism weaving process. 

We believe that the CRX model is a good way to explain and 
teach AOP [10]. Data flow analysis is effective for conceptual level 
modeling, and a DFD provides an easy to understand graphical rep- 
resentation of a system [24]. Of course, a data flow description of 
the weaving process is just a step toward a complete definition or a 
blueprint of an aspect mechanism. Documenting the weaving pro- 
cess also in terms of state transitions is another logical follow-up to 
this work. 
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